Three follow-up bugs to the initial ARB-515 fix surfaced in production
(users like theo@reinsberg.info still showed their Kinde `sub` as their
display name even after my earlier PR and after being touched in cohort
flows):

1. `check_admin` in `main.rs` called `ensure_global_user(&sub, &sub, ...)`
   unconditionally. Since admins hit REST endpoints frequently and
   `ensure_global_user` updates `display_name` whenever it differs, every
   admin REST request silently overwrote the user's real display name back
   to their Kinde sub. Switch `check_admin` to `find_or_create_global_user`,
   which syncs `is_kinde_admin` but never touches the display name.

2. The WS auth path in `handle_socket.rs` used `"Unknown"` as a fallback
   when the id_token lacked a `name` claim and then called `ensure_global_user`
   with that fallback, overwriting good names with "Unknown" for any user
   whose Kinde account has no full-name claim. The WS auth flow now takes
   the same two-mode approach as `list_cohorts`: when there's a trusted
   id_token name we call `ensure_global_user`; otherwise we fall back to
   `find_or_create_global_user` with the email (or sub) as a create-time
   placeholder, which never clobbers an existing name. The cohort-db
   account creation below now reuses `global_user.display_name` directly.

3. `IdClaims` required a `name: String` claim, so users whose Kinde token
   omitted `name` entirely either failed validation or ended up with an
   empty string. Make it `Option<String>`, add `given_name`/`family_name`
   fields, and add `IdClaims::resolve_name()` which prefers `name`,
   falling back to a trimmed `given_name` + `family_name` concatenation.
   Both `validate_access_and_id` and `validate_id_token_for_sub` now go
   through `resolve_name()`.

Also: `list_cohorts` now uses the resolved email as the create-time
placeholder instead of the sub, so brand-new users without any id_token
name claim still land with a recognisable name from the start.

Finally, add a global-DB migration that backfills existing rows where
`display_name = kinde_id` or `display_name = 'Unknown'` with the user's
email when one is available, so users broken by the earlier behaviour
get rescued without having to wait for a login that re-populates them.

Following up on the previous ARB-515 commit: `ensure_global_user` still
overwrote `display_name` whenever the trimmed id_token name differed
from the stored value, which silently clobbered any name the user or an
admin had set through `/api/users/me/display-name` or
`/api/admin/users/:id/display-name` on the next login. From the user's
perspective, manual renames just "didn't stick".

- `ensure_global_user`: stop touching `display_name` on existing rows.
  The `name` parameter is now only used on creation. `email` and
  `is_kinde_admin` are still synced so email changes and Kinde admin
  revocations still propagate.

- `check_admin`: no longer calls `find_or_create_global_user`, which
  would insert a placeholder row with the Kinde sub as the display
  name for any admin who somehow hit an admin endpoint before the
  main app. It now uses a new `sync_is_kinde_admin_by_kinde_id`
  helper that looks the user up, syncs the Kinde admin flag in
  place, and returns `None` (→ 403) when the row doesn't exist.
  Admins always reach admin endpoints after `/api/cohorts`, which
  creates the row with a real name.

- `update_my_display_name`: no longer pre-creates the caller's row
  with their Kinde sub as the display name. It now looks the row up
  and returns 404 if missing, same reasoning as `check_admin`.

With these changes, the only remaining code paths that can write the
Kinde sub as a user's display_name are the creation fallbacks in
`list_cohorts` and the WS auth handler, and only when *both* the
id_token is missing/invalid *and* the access token carries no email —
a scenario that only arises for direct API callers or dev-mode test
tokens without an email field.

Neither the Kinde sub nor the user's email should ever surface as a
display name in the UI. Move placeholder generation into
`find_or_create_global_user` so callers can't accidentally reach for the
sub or email: the function now takes no `placeholder_name` argument and
generates an `Unnamed-XXXX` string via a new `generate_unnamed_placeholder`
helper (4 random alphanumeric chars, so two simultaneously-created
unnamed users in the same account list are still distinguishable).

Update `list_cohorts` and the WS auth handler to call the trimmed-down
signature, and rewrite the backfill migration to replace any existing
row where `display_name` equals the Kinde sub, the user's email, or
the literal `"Unknown"` with a fresh `Unnamed-XXXX` suffix per row
(`randomblob()` is volatile in SQLite, so it's re-evaluated per updated
row — verified manually against a throwaway DB).